昨天我們已確認將採用那些雲端元件。今天，我們將這些元件實際整合至系統架構圖中，並進行初步的驗證。

各元件功能說明

• Sales Service：作為系統的門面，所有使用者皆透過此服務進行購票。此服務將承載主要的流量，並負責將使用者請求轉發至後端服務，後續效能調教會需要針對此服務特別做調整。
• Memorystore：扮演系統的快取層，用以儲存頻繁存取的售票資訊，例如商品資訊、庫存數量、座位選項等。透過 Memorystore，我們可大幅降低資料讀取的延遲，提升系統響應速度。
• Pub/Sub：作為訊息傳遞的緩衝區，將 Sales Service 與 Process Service 解耦。當 Sales Service 面臨大量購票請求時，可將資料委託給 Pub/Sub，避免單一服務過載。Process Service 將從 Pub/Sub 訂閱訊息，並依序處理，確保資料的可靠性。
• Process Service：負責處理資料的持久化與其他後續作業。需要對 Auto Scaling 做一些限制，根據系統負載自動調整執行個體數量，以達到成本效益。
• Cloud SQL：作為系統的資料庫，用以儲存最終的購票紀錄。Cloud SQL 提供高可用性與彈性擴展能力，確保資料的安全性與一致性。

你可能會想，為什麼需要一個 Pub/Sub 在中間，直接寫入 Cloud SQL 不就好了嗎？

的確，在日常流量不高的情況下，直接寫入 Cloud SQL 是沒問題的。但當短時間內高流量湧入時，Cloud SQL 可能會無法承受，尤其是因為 Cloud SQL 的費用不低，我們的配置也沒有開到非常高的 IOPS。Pub/Sub 能夠承受非常高的流量（預設 asia-east1 可達到 800 MB/s），而且價格非常便宜，每月前 10GB 都免費，我們可能連免費額度都用不完，這能大幅降低成本。